The BioDT Recreational Potential Model

Summary

Authors

Affiliation

Joe Marsh Rossney

UK Centre for Ecology & Hydrology

Maddalena Tigli

Chris Andrews

Jan Dick

Simon Rolph

Abstract

This report introduces the Recreational Potential model and describes key aspects of its functionality.

1 Background

TODO Brief history of recreational potential work, with references

ESTIMAP (“Ecosystem Service Mapping Tool”) is a collection of spatially explicit models, originally developed to support policies at a European scale (Zulian et al. 2013, 2018; Paracchini et al. 2014).

OpenNESS project 2012-2017 (Zulian et al. 2018). (note www.openness-project.eu has been abandoned)

Something something Long Term Socio-Ecological Research Platforms (LTSER) (Dick et al. 2018)

BioDT project 2022-2025, outputs include (Rolph et al. 2024; Dick et al. 2025).

SPEAK has something to do with Powell2024 ?

TODO Brief introduction to BioDT, the CES project and the recreational potential component. (Dick et al. 2022; Rolph et al. 2024)

The BioDT consortium … As a member of this Cultural Ecosystem Services (CES) Digital Twin (DT).

The CES DT was imagined as a platform that brings together near real time data from a wide range of sources in a manner that is somehow tailored to the individual user. The proposed pDT focuses on two components:

1. The Recreational Potential (RP) component aims to estimate the capacity of a given area to sustain the recreational activities valued by an individual user.
2. The Biodiversity aims to predict biodiversity levels ==(abundance?)== across mammals, birds, plant and insects.

The rationale behind bringing these two components together into a unified framework is that encountering interesting flora or fauna can enrich people’s recreational experiences, and help them to discover new ways to value nature-rich landscapes.

The driving motivation for this work is to promote good health and connection to nature through physical activity outdoors. However, there is also a possible synergy with conservation science, which is increasingly using data collected by non-scientists through ‘citizen science’ apps such as iNaturalist and iRecord. Potentially, certain users could be encouraged to visit areas where there is a greater need for sampling, (see also DECIDE project ==citation?==).

The RP component and the biodiversity component are distinct models that have been developed independently of each other. However, in both cases their outputs can be displayed on an interactive map of Scotland and served to users using an app framework such as R Shiny (Chang et al. 2025).

Earlier on in the BioDT project, rudimentary versions of the RP and biodiversity components were combined in a single raster overlay. However, this was limited to pre-calculated ‘static’ raster layers covering a small region (the Cairngorms National Park) rather than all of Scotland (Rolph et al. 2024). Since then, work has focused on improving the speed and scalability of these components, to enable the interactive and personalisable experience that was envisaged.

In this short report we will describe basic aspects of the Recreational Potential model. For a detailed account of the inner workings of the model the reader is directed to the accompanying technical supplement. The Biodiversity component is described in ==TODO: ref==.

2 Model description

2.1 Overview

To describe the Recreational Potential model we will start from its outputs and work backwards.

The main model output is an two-dimensional array of numbers (a raster) representing an RP value between \(0\) and \(1\) for each 20x20 metre square area of land (pixel) within a given area, with higher values indicating greater Recreational Potential for that specific persona. These RP values can then be mapped to colours and displayed as a heat map over a map of Scotland, as illustrated in Figure 1.

Figure 1: An example of a heat map displaying Recreational Potential.

An RP value is constructed from a combination of 87 items representing distinct attributes of the land. The 87 items are grouped into four components, which are outlined in Table 1. RP values are calculated by weighting each item by a score between \(0\) and \(10\) that reflects the importance of that item to the user. A full set of 87 scores is referred to as a persona.

Component	Short code	# items
Landscape - the suitability of land to support recreational activity	SLSRA	40
Natural Features influencing the potential	FIPS_N	24
Infrastructure features influencing the potential	FIPS_I	10
Water - rivers and lakes	Water	13

Table 1: The four components contributing to Recreational Potential values.

The RP model thus requires two inputs from users:

1. A persona, i.e. the 87 scores for each item/feature, contained in a .csv file.
2. A region of interest, i.e. an area within Scotland in which to calculate RP values, given by either a shapefile or the four coordinates of a bounding box.

We will often refer to the computations that produce an RP raster from the two user inputs as the ‘dynamic’ part of the RP model, since these computations must be performed each time the user makes a change to their persona or region of interest. The dynamic part is outlined in Figure 2.

flowchart LR
 subgraph s1["compute recreational potential"]
        C[("cropping of the 4<br>components file to the<br>extent of interest")]
        E["Compute each component's<br>contribution"]
        F["Rescale to unit interval"]
  end
    A("Definition of the<br><i>persona preferences</i>") ---> E
    B("Definition of the<br><i>area of interest</i>") --> C
    C --> E
    E --> F
    F --> G["recreational potential spatRast"]
    style s1 fill:#FFF9C4
    style A color:#000000
    style B color:#000000
    style C color:#000000
    style E color:#000000
    style F color:#000000
    style G color:#000000

Figure 2: A breakdown of the ‘dynamic’ part of the Recreational Potential model, that responds to changes in user input.

2.2 Persona

As previously stated, a persona is nothing more than a set of 87 numbers between \(0\) and \(10\) corresponding to each of the 87 items.

Personas are stored in .csv files. However, the interactive R Shiny app provided with the model (Section 3.7) contains a convenient interface for loading, saving and editing personas. Figure 3 is a screenshot from this app, showing some example persona scores for the Water component.

Figure 3: An example set of persona scores for the ‘Water’ component.

2.3 Input data

There is another essential set of inputs to the model which are not specified by the user. These are a set of 87 raster layers — one for each of the 87 items — covering Scotland at a resolution of 20x20m.

For items belonging to the Landscape (SLSRA) component or the Natural Features component (FIPS_N), these rasters contain just ones and zeros, with \(1\) indicating presence of the feature in that pixel and \(0\) indicating absence.

\[ \mathrm{SLSRA}_j = \begin{cases} 1 & \text{if feature} \; j \; \text{present in pixel} \\ 0 & \text{if feature} \; j \; \text{absent in pixel} \end{cases} \]

==TODO: screenshot of one of these layers==

For items belonging to the Infrastructure (FIPS_I) component or the Water (Water) component, the input rasters contain values between zero and one.

\[ \mathrm{Water}_j = \begin{cases} 1 & \text{if feature} \; j \; \text{present in pixel} \\ 0 & \text{if feature} \; j \;\gtrapprox 500\text{m away} \\ u(\mathrm{distance}_j) & \text{otherwise} \end{cases} \]

where \(\mathrm{distance}_j\) is the distance to the nearest pixel in which the feature \(j\) is present, and \(u(d)\) is a function that takes distances \(d\) as input, and outputs values between \(0\) and \(1\), decreasing as \(d\) increases, and falling to zero at a distance of approximately 500m (see Eq. (==X==) in the Technical Supplement for details).

==TODO: screenshot of a layer with/without the proximity part==

Thus, \(1\) still indicates presence of the feature in that pixel, but \(0\) instead indicates that the feature is not only absent in that pixel, but all surrounding pixels within 500m. The range of values between zero and one are used to signify that the feature is nearby (within 500m), but not present in this pixel itself.

This continuous scale allows the RP model to incorporate how areas near e.g., a loch, can still contribute to the recreational potential, even if they do not directly contain the feature.

2.4 Recreational Potential calculation

Each of the four components is calculated by multiplying the item/features by the corresponding persona score, summing, and normalising the result,

\[ \mathrm{SLSRA} = \mathrm{normalise}\left( \sum_j \mathrm{Score}^{(\text{SLSRA})}_j \times \mathrm{SLSRA}_j \right) \, . \]

In this context, ‘normalisation’ means transforming the values so that they lie between \(0\) and \(1\), through the following transformation:

\[ \mathrm{normalise}(x) = \frac{x - x_\text{min}}{x_\text{max} - x_\text{min}} \, . \]

The final RP value is calculated by summing these four components and normalising once more,

\[ \mathrm{RP} = \mathrm{normalise} \left( \mathrm{SLSRA} + \mathrm{FIPS\_N} + \mathrm{FIPS\_I} + \mathrm{Water} \right) \, . \]

The effect of changing the region of interest

An important detail is that the normalisation step depends on the minimum and maximum values within the chosen region of interest. This means that running the model with a different region of interest (e.g. over a larger area) will generally yield different values for the same locations, even if both the persona and the underlying data are unchanged.

3 Model code

3.1 Brief history of development work

The RP model for Scotland has been gradually developed within UKCEH over a number of years, with various contributors.

• ==TODO early history. Originally copied from someone else’s python model?==
• TODO When was the calibration etc done?
• Add SPEAK study

Time period	Activity	References
2023	Code development	https://github.com/BioDT/uc-ces/tree/main/recreation_model
2024		https://github.com/BioDT/uc-ces-recreation/tree/2024-model
Jan-June 2025		Version used in SPEAK study: https://github.com/BioDT/uc-ces-recreation/tree/SPEAK-prerelease Development version: https://github.com/BioDT/uc-ces-recreation

Table 2: History of development for the Recreational Potential model.

3.2 Overview of the repository

Source code for the most recent version of the RP model can be found on GitHub at https://github.com/BioDT/uc-ces-recreation. This may be more up-to-date than the version of the code published on Zenodo.

The repository is organised in the following way:

├── CONTRIBUTING.md
├── DESCRIPTION
├── inst
│   ├── examples
│   │   ├── capture_messages.R
│   │   ├── compute_component.R
|   |   ...
│   │   └── save_persona.R
│   ├── extdata
│   │   ├── config
│   │   │   └── config.csv
│   │   ├── personas
│   │   │   └── presets.csv
│   │   ├── rasters
│   │   │   ├── Bush
│   │   │   │   ├── FIPS_I.tif
│   │   │   │   ├── FIPS_N.tif
│   │   │   │   ├── SLSRA.tif
│   │   │   │   └── Water.tif
│   │   │   └── Scotland
│   │   │       ├── FIPS_I.tif
│   │   │       ├── FIPS_N.tif
│   │   │       ├── SLSRA.tif
│   │   │       └── Water.tif
│   │   └── shapefiles
│   │       ├── Bush
│   │       │   ├── Bush.cpg
│   │       │   ├── Bush.dbf
│   │       │   ├── Bush.prj
│   │       │   ├── Bush.shp
│   │       │   └── Bush.shx
│   │       └── Scotland
│   │           ├── Scotland.cpg
│   │           ├── Scotland.dbf
│   │           ├── Scotland.prj
│   │           ├── Scotland.shp
│   │           └── Scotland.shx
│   └── scripts
│       ├── cli
│       │   ├── app.sif
│       │   ├── main.R
│       │   └── README.md
│       └── data_production
│           ├── app.sif
│           ├── main.R
│           └── README.md
├── LICENSE
├── LICENSE.md
├── man
│   ├── assert_to_bool.Rd
│   ├── assert_valid_bbox.Rd
│   ...
│   └── timed.Rd
├── NAMESPACE
├── R
│   ├── app_run.R
│   ├── app_server.R
│   ├── app_text.R
│   ├── app_theme.R
│   ├── app_ui.R
│   ├── bbox.R
│   ├── config.R
│   ├── data_download.R
│   ├── data_input.R
│   ├── data_production.R
│   ├── example.R
│   ├── legacy.R
│   ├── persona.R
│   ├── recreation.R
│   └── utils.R
├── README.md
├── renv.lock
├── dev
│   ├── cli_test.sh
│   ├── dev.sh
│   ├── pre-commit.R
│   ├── README.md
│   └── run_app.sh
├── tests
│   └── testthat
│       └── test_io.R
└── vignettes
    ├── compute_potential.qmd
    ├── personas.qmd
    └── run_app.qmd

1

Instructions for potential contributors.

2

The standard DESCRIPTION file for R packages, containing metadata about the package.

3

Simple examples using the package functions, which get included in the generated documentation.

4

Configuration file, mapping layer names to raster values (for the pre-processing step) and descriptions (used in the Shiny app).

5

File containing two ‘preset’ personas: the ‘hard’ and ‘soft’ recreationalists described in Rolph et al. (2024).

6

Dataset covering a small area, for use in examples and vignettes.

7

Dataset for all of Scotland. This is not included in the package and is instead downloaded separately.

8

Shapefile and auxiliary data for the example dataset.

9

Shapefile and auxiliary data for the full Scotland-wide dataset.

10

Container definition file used to build a Singularity container for cli/main.R.

11

Command-line script for the model taking a persona and bounding box as input. This is expected to be called from the main BioDT app.

12

Container definition file used to build a Singularity container for data_production/main.R.

13

Script that executes all steps of the data pre-processing pipeline.

14

MIT licenses (.md for the repository, no extension for the package).

15

Compiled documentation for the package, generated using roxygen2.

16

The standard NAMESPACE file for R packages, containing a list of functions provided by the package.

17

Source code for the package.

18

renv lockfile used (in theory) to install packages deterministically. Used when deploying app to Posit Connect.

19

Bash script that runs Rscript inst/scripts/cli/main.R with example data.

20

Bash script that runs pre-commit if available, or else Rscript scripts/pre-commit.R, as well as the tests.

21

R script that emulates the behaviour of pre-commit when run, in case the latter is not installed.

22

Bash script that loads the local version of the package and runs the Shiny app, for convenience during development.

23

A file containing unit tests. Essentially tokenistic, but provides a template for more unit tests to be added in future.

24

Some vignettes demonstrating simple use of the package.

3.3 Package structure

The code is bundled as an R package. This has a number of advantages compared with a stand-alone script, since the standardised setup allows us to leverage tools for installing, documenting and testing the code, and managing its dependencies on other packages.

In particular, the package may be installed by passing the GitHub repository to remotes::install_github (or the devtools function with the same name).

remotes::install_github("BioDT/uc-ces-recreation")

This will install the package, which is named biodt.recreation. It will also install the packages upon which biodt.recreation depends, which are listed under Imports in the DESCRIPTION file.

Functionality is provided through a collection of functions in the R/ directory that, after installing the package, are accessible to the user in the biodt.recreation namespace. That is, functions such as compute_potential are accessed using the syntax biodt.function::compute_potential, or by name alone after exposing the whole namespacing using library(biodt.recreation).

Documentation for these functions is contained in the .Rd files within the man/ directory. This documentation can be brought up in RStudio.

==TODO: screenshot of documentation==

3.4 Downloading the input data

Input data for the RP model is not available in precisely the form required by the model, as described in Section 2.3. Rather, these input rasters are obtained through a series of processing steps which combine and transform ‘raw’ data downloaded from various open-access datasets.

Currently, this ‘data production’ process is split into a manual stage and an automated stage. The automated stage is carried out by a script in the inst/scripts/data_production/ directory.

However, users need not run this script; the data which it produces is stored on Dropbox ==(soon moved to Zenodo)== and can be downloaded by calling a function provided by the package.

# Allow 10 minutes for the download before timing out!
options(timeout=600)  

biodt.recreation::download_data()

In an ideal world this data production ‘pipeline’ would be entirely automated through one or more scripts. This would enable the input data to be more easily regenerated and updated in future.

3.5 Calculation of RP values

As stated earlier, the RP model requires two user inputs to run: a persona and a region of interest.

For this demonstration, we will use one of the ‘preset’ personas, which is loaded using the function get_example_persona(). We will also load an example bounding box which covers an area just south of Edinburgh.

The following snippet of code demonstrates how to compute Recreational Potential. The function also returns each component individually.

library(biodt.recreation)

persona <- get_example_persona()
bbox <- get_example_bbox()

layers <- compute_potential(persona, bbox)

The output of this function, layers, is a five-layered raster, whose layers are the four component layers plus the RP layer, as described in Section 2.4.

3.6 ‘Preset’ personas

The code snippet above made use of two convenience functions for constructing a persona and a bounding box.

A persona is represented by a very specific type of object in R (a named vector with 87 elements and specific names). It is therefore unlikely that users will want to create one from scratch without using the Shiny app interface.

We provide two ‘preset’ personas along with the package. These are

1. Hard Recreationalist: this persona values remote, challenging environments and avoids built-up or highly managed areas.
2. Soft Recreationalist: this persona values tranquil, accessible landscapes and natural water features, and avoids steep or harsh terrain.

==TODO: some detail about these. When/how where these personas created?==

Preset personas can be loaded into an R session as follows:

# Get the path to the preset persona file
persona_file <- get_preset_persona_file()

# Load the Hard Recreationalist persona
hard_recreationalist <- load_persona(persona_file, "Hard_Recreationalist")

# Load the Soft Recreationalist persona
soft_recreationalist <- load_persona(persona_file, "Soft_Recreationalist")

In fact the function get_example_persona() loads the Hard Recreationalist persona.

A note on the inst/ directory

Apparently it has become standard practice to use the inst/ directory to distribute additional elements such as scripts and Shiny apps along with the package. This is the practice we have adopted here. There are really just two important things to know about the inst/ directory:

First, that its contents are copied to the top-level of the package when the package is built. Hence, the top level of the built package will contain examples/, extdata/ and scripts/ (the directory containing shell scripts is not included in the package).

Hence, in order for file paths to work when the package is installed, one must omit inst/ from the path. But this means the path will not work during development.

The way to regain consistency between the two situations (installed versus not installed) is to usesystem.file. There are several examples of this in the code, including the one below, where paths to files or directories under inst/ needed to be constructed.

get_preset_persona_file <- function() {
    system.file("extdata", "personas", "presets.csv",
        package = "biodt.recreation", mustWork = TRUE
    )
}

The strongest preferences of the Hard Recreationalist persona are highlighted in Table 3.

Loading persona 'Hard_Recreationalist' from file '/home/joe/github.com/BioDT/ces-recreation-reports/renv/library/linux-ubuntu-jammy/R-4.5/x86_64-pc-linux-gnu/biodt.recreation/extdata/personas/presets.csv'

score_group	features
highest scores (scored 10 or 9)	Rock Walls (FIPS_N), Mountains (FIPS_N), Inland cliffs, rock pavements and outcrops (SLSRA), Rock cliffs, ledges and shores (SLSRA), National Park (SLSRA)
lowest scores (scored 0 or 1)	Built-up areas (FIPS_N), Flood plain (FIPS_N), Depressions (FIPS_N), No slope (FIPS_N), Gentle slope (FIPS_N), Country Park (SLSRA), Raised and blanket bog (SLSRA), Valley mires, poor fens and transition mires (SLSRA), Windthrown woodland (SLSRA), Woodland fringes and clearings and tall forb stands (SLSRA), Bare field or exposed soil (SLSRA), Built-up area (SLSRA), Royal Society for the Protection of Birds (RSPB) Reserve (SLSRA), Pond (Water), Motorway (FIPS_I), A Road (FIPS_I), B Road (FIPS_I), Minor or local road (FIPS_I), Access roads or Track (FIPS_I), Saltings (FIPS_N)

Table 3: Highest and lowest scores in the Hard Recreationalist persona.

The strongest preferences of the Soft Recreationalist persona are highlighted in Table 3.

Loading persona 'Soft_Recreationalist' from file '/home/joe/github.com/BioDT/ces-recreation-reports/renv/library/linux-ubuntu-jammy/R-4.5/x86_64-pc-linux-gnu/biodt.recreation/extdata/personas/presets.csv'

score_group	features
highest scores (scored 10 or 9)	Traffic Free: Paved Surface (FIPS_I), Coastal dunes and sandy shore (SLSRA), National Park (SLSRA), Major Lochs (Water), Beaches or Dunes (FIPS_N), No slope (FIPS_N), Freshwater (SLSRA), Mixed deciduous and coniferous woodland (SLSRA), Scots pine woodland (SLSRA), Broadleaved deciduous woodland (SLSRA)
lowest scores (scored 0 or 1)	Rock Walls (FIPS_N), Built-up areas (FIPS_N), Rocks or Scree (FIPS_N), Depressions (FIPS_N), Extremely steep slope (FIPS_N), Screes (SLSRA), Windthrown woodland (SLSRA), Bare field or exposed soil (SLSRA), Unnamed minor stream or tributary (Water), Motorway (FIPS_I), A Road (FIPS_I), Saltings (FIPS_N)

Table 4: Highest and lowest scores in the Soft Recreationalist persona.

3.7 Shiny app

As part of the SPEAK study an R Shiny app was developed that focused exclusively on the Recreational Potential model. This is provided alongside the main package, since it provides a convenient, dynamic interface for testing and visualising outputs.

The source code for the app is split across several files, each containing the app_ prefix:

• app_ui.R contains a function make_ui that returns the user interface (UI), i.e. the layout of the Shiny app, sliders, map, buttons etc.
• app_server.R contains a function make_server that returns the server function, which defines the dynamic parts of the app, such as loading/saving/editing personas and drawing a rectangle on the map.
• app_theme.R contains some custom UI elements such as the colour scheme and logo.
• app_text.R contains the extended text elements of the app, such as the user guide.
• app_run.R contains a convenience function run_app for running the app.

The app can be run from an R session by calling the run_app() function:

biodt.recreation::run_app()

If you are in RStudio this should launch the app in a separate pane. To launch the app in your default browser, you can pass the option launch.browser = TRUE to the function.

Detailed instructions for using the app are contained within the app itself, in the ‘User Guide’ tab. However, the essential steps are:

1. Create a persona using the ‘Persona’ tab.
2. Draw a box on the map by clicking the square orange button and dragging your mouse over the map.
3. Click the ‘Update Map’ button to compute the Recreational Potential value.

4 Interactive example

build_rp_map(base_map, RP_output = layers)

5 Known limitations (to do)

As things stand, personas are stored in .csv files on the server side. This means the app requires write access to the server’s filesystem. This is convenient, since users do not have to upload their own persona files. However, it is not a scalable solution. Future work should take a different approach to handling user’s personas, such as providing the option to link the app to Google sheets.

• The model is very fast and embarrassingly parallel - therefore can scale very well, to large areas and/or high resolutions.
  • However, the use-case for large areas is unclear, and the resolution depends on the datasets being used.
• The data production pipeline could be improved:
  • Fully automated / scripted would allow easier updating with more / updated datasets
  • Also reproducibility and transparency of how the data was produced (many users wanted to know more about the input data)
• Use of rasters is a problem for linear features
  • Use vector layers for linear features and distance
  • This would also make data production easier

Certain limitations, caveats and suggestions of a more technical nature are discussed in the developer’s report.

6 Future directions (to do)

• Digital twin?

1. Simplifying feature scoring

   Currently, the model requires users to score 87 individual features across the four components. While this allows for a detailed definition of the “persona profile”, it can be time-consuming for users. A future version could:

   • Group similar features into broader thematic categories (e.g., “mountain terrain,” “urban infrastructure,” “wetlands”), allowing users to score these aggregated categories rather than individual layers, making the scoring process more intuitive and efficient

   • Maintain the option to score each of the 87 featre for expert users who want fine control

   A simpler model configuration could make the model accessible to more users.

2. Connecting to Live, regularly updated data-sets

   Currently the model relies on static raster layers to represents the components, which may become outdated as landscapes change or as better data becomes available. A future version of the model could:

   • Link the model to live/regularly updated data-sets
   • Automatically generate the “original” raster layers for each component when updated data becomes available

3. User-defined weighting components

   Currently the RP model assumes that all four components contribute equally to the Recreational Potential score. However, not all personas may value these components equally. A future version of the model could:

   • Allow users to specify custom weights for each of the four components (e.g. ,50% landscape, 20% water, 15% infrastructure and 15% natural features)

4. Expanding the number of Persona presets available

   To make the RP model more accessible to casual non-technical users, and to encourage exploration and experimentation with it, a future version of the model could:

   • Provide persona preset for common user types (e.g., hikers, birdwatchers, families, cyclists etc.)
   • Define both features scores and components weights for each persona

5. Include seasonal dynamics

   Currently, the RP model assumes a static Recreation Potential throughout the year, however, this can vary with seasons, and weather conditions. A future version of the model could:

   • integrate temporal layers by asking the persona to specify what season they are intending to recreate in. Then the model could have the underlying components starting values to have different values for different seasons, accounting for trail closures or flooding risks etc.)

6. Allow for “future scenarios”

   With the aim of making the RP model the more relevant to policy makers and stakeholders, a future version of the model could:

   • have a “scenario analysis” mode, where users can “add” or “remove” values underlying components (e.g., to simulate a new trail or a new cycle path being added or the change of a landscape due to climate change or socio-economic changes)
   • allow for direct comparison on how the two (or more) scenarios differ (provide the user with a decrease or increase of Recreational Potential raster.

7. JOE and CHRIS to add something if you have other ideas

7 Access to code & data

Code for the Recreational Potential model is available as an R Package hosted on GitHub at https://github.com/BioDT/uc-ces-recreation.

The model requires some input data, which has been deposited on Zenodo HERE.

The source for these documents and this website can be found at https://github.com/BioDT/ces-recreation-reports.

8 Funding

Funding for OpenNESS came from the European Community’s Seventh Framework Programme (FP7/2007-2013) under grant agreement no 308428, OpenNESS Project (Operationalisation of Natural Capital and Ecosystem Services: From Concepts to Real-world Applications.)

Funding for BioDT came from the European Union’s Horizon Europe Research and Innovation Programme under grant agreement No 101057437 (BioDT project, https://doi.org/10.3030/101057437)

Funding for SPEAK came from the Natural Environment Research Council – Growing Shoots Partnership and application co-creation bursary. NE/Y005805/1 _Growing Shoots.

9 CRediT statement

JMR and MT developed the current version of the model, and wrote the original drafts of these reports. CA obtained the input data and developed the previous version of the model. CA and JD conceptualised the SPEAK project and carried out the ananalysis. CA, JD and SR acquired funding for the project under BioDT.

Missing anything important? See https://www.elsevier.com/en-gb/researcher/author/policies-and-guidelines/credit-author-statement

10 Acknowledgements

We wish to acknowledge contributions to previous versions of the Recreational Potential model by Will Bolton, … .

JMR would like to thank Tomáš Martinovič for assisting with understanding the requirements of BioDT.

Dylan Powell?

We are very grateful to all the participants of the SPEAK project which this output is based on including: Alastair Leaver, Alice MacSporran, Brian Cassidy, Chris Pollock, David Giles, Jean Cowie, Joanna Gilliatt, Justyna Olszewska, Laura Taylor, Maddi Bunker, Rebecca MacLennan, S Mayes, Shaila Rao, Steve MacKinnon and Tom Gebbie, Active Stirling. We are equally grateful to an additional 18 participants who preferred to remain anonymous.

11 Correspondence

• {jand,chan}@ceh.ac.uk for enquiries relating to the BioDT or SPEAK projects, or ongoing and future work.

• chan@ceh.ac.uk for enquiries relating to the data sources and QGIS processing.

• {joemar,madtig}@ceh.ac.uk for enquiries relating to the code and anything else appearing in the technical supplement and/or developer’s report.

• simrol@ceh.ac.uk for enquiries relating to the biodiversity component of the BioDT project.

References

Chang, Winston, Joe Cheng, JJ Allaire, Carson Sievert, Barret Schloerke, Yihui Xie, Jeff Allen, Jonathan McPherson, Alan Dipert, and Barbara Borges. 2025. Shiny: Web Application Framework for r. https://shiny.posit.co/.

Dick, Jan, Chris Andrews, Daniel E. Orenstein, Yael Teff-Seker, and Grazia Zulian. 2022. “A Mixed-Methods Approach to Analyse Recreational Values and Implications for Management of Protected Areas: A Case Study of Cairngorms National Park, UK.” Ecosystem Services 56 (August): 101460. https://doi.org/10.1016/j.ecoser.2022.101460.

Dick, Jan, Dylan Carbone, Kata Sara-aho, Chris Andrews, and Tomáš Martinovič. 2025. “Consultation on BioDT Draft Cultural Ecosystem Service Digital Twin: Responses to Structured Interviews BES 2024.” Project Report. UK Centre for Ecology & Hydrology. https://nora.nerc.ac.uk/id/eprint/538779/.

Dick, Jan, Daniel E. Orenstein, Jennifer M. Holzer, Christoph Wohner, Anne-Laure Achard, Christopher Andrews, Noa Avriel-Avni, et al. 2018. “What Is Socio-Ecological Research Delivering? A Literature Survey Across 25 International LTSER Platforms.” Science of The Total Environment 622–623 (May): 1225–40. https://doi.org/10.1016/j.scitotenv.2017.11.324.

Paracchini, Maria Luisa, Grazia Zulian, Leena Kopperoinen, Joachim Maes, Jan Philipp Schägner, Mette Termansen, Marianne Zandersen, Marta Perez-Soba, Paul A. Scholefield, and Giovanni Bidoglio. 2014. “Mapping Cultural Ecosystem Services: A Framework to Assess the Potential for Outdoor Recreation Across the EU.” Ecological Indicators 45 (October): 371–85. https://doi.org/10.1016/j.ecolind.2014.04.018.

Rolph, Simon, Chris Andrews, Dylan Carbone, Julian Lopez Gordillo, Tomáš Martinovič, Nick Oostervink, Dirk Pleiter, et al. 2024. “Prototype Digital Twin: Recreation and Biodiversity Cultural Ecosystem Services.” Research Ideas and Outcomes 10 (June). https://doi.org/10.3897/rio.10.e125450.

Zulian, Grazia, Maria-Luisa Paracchini, Joachim Maes, and Maria Del Camino Liquete Garcia. 2013. ESTIMAP: Ecosystem Services Mapping at European Scale. LU: Publications Office of the European Union. https://doi.org/10.2788/64369.

Zulian, Grazia, Erik Stange, Helen Woods, Laurence Carvalho, Jan Dick, Christopher Andrews, Francesc Baró, et al. 2018. “Practical Application of Spatial Ecosystem Service Models to Aid Decision Support.” Ecosystem Services 29 (February): 465–80. https://doi.org/10.1016/j.ecoser.2017.11.005.

Copyright

UK Centre for Ecology & Hydrology, 2025